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ABSTRACT 



A method and system provide for adaptive coding for 
transporting of compressed video data. The method and 
system include techniques for predicting the rate which an 
encoder needs to be able to supply video to a network. The 
method and system also include the network receiving the 
demand rate and calculating an allocation rate which is 
ultimately fed back to the video source setting an explicit 
rate for the transporting of compressed video. Furthermore, 
it includes the adaptation of the encoding rate at the video 
source in accordance with the explicit rate allocated by the 
network in response to the demand. 

18 Claims, 6 Drawing Sheets 
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METHOD AND APPARATUS FX)R 
SUPPORTING COMPRESSED VIDEO WITH 
EXPLICIT RATE CONGESTION CONTROL 

BACKGROUND OF THE INVENTION 

The present invention relates to a method and apparatus 
for transmitting video data while controlling congestion 
through a network in which the video is transmitted. More 
particularly, the present invention relates to support for 
compressed video providing expLcit rate congestion control 
including adapting the rate of encoding the video. 

More and more frequently, video information is the sub- 
ject of data transfers through existing networks. Examples of 
such a video trafiSc include video data associated with a 
real-time communication such as a video teleconference and 
pre-stored video entertainment information. It is well known 
to provide mechanisms for compressing the video data to 
facilitate the transfer of video over existing networks. Com- 
pressed video trafi&c is likely to form a significant compo- 
nent of the workload of future networks. 

FIG. 1 illustrates, in schematic form, an example of a 
known video transmission system. A video encoder/ 
transmitter 10 receives video signals at its input 11 and 
produces compressed video data at its output 12. The 
compressed video information is sent into the network 20 
where it traverses a number of switches, for example 21, 22 
and 23 as it is routed to its intended destination, here shown 
as receiver/decoder 30. The receiver then takes the encoded 
information, decodes it and outputs the video signal. 

It is also known that the video encoder can provide some 
adaptive control so as to govern the rate at which the 
compressed video, which is known to be inherently bursty is 
provided to the network. An example of a known adaptive 
encoder is illustrated in FIG. lA. In this known encoder the 
video received at input 11 is provided to the transform 
device 13. The transform device creates the encoded data 
and transfers that encoded data to internal buffer 14. The 
internal buffer then outputs encoded data to the network 
through the output 12. If the transform device 13 is encoding 
data faster than the buffer is outputting data then the buffer 

14 begins to fill. A feedback mechanism as indicated by line 

15 permits the buffer to notify the transformer of the status 
of the buffer so as to allow the transformer 13 to adapt its 
encoding rate to avoid overfill of the buffer. If the trans- 
former is encoding video at a rate slower than the buffer is 
outputting data then the buffer could run dry if the feedback 
mechanism was not in place to advise the transformer 13 to 
increase its rale of encoding. 

Work has already been done in examining how to transmit 
compressed video over Asynchronous Transfer M (ATM) 
networks. In fact, a number of different methods have been 
proposed. These methods attempt to exploit different service 
classes that the underlying ATM network is capable of 
transporting. The classes of services offered by ATM net- 
works include: Constant Bit Rate (CBR), Variable Bit Rate 
(VBR), the best-effort classes of service. Available Bit Rate 
(ABR), and Unspecified Bit Rate (UBR). 

In a proposal to transmit compressed video using the CBR 
service, the inherently variable bit rate output of a video 
encoder is locally buffered in the encoder to convert it into 
a CBR stream. Thus, in the example shown in FIG. lA, the 
buffer 14 operates to produce a constant bit rate output at 12 
while providing feedback to the transfonner 13 to adjust the 
encoding rate of the transformer so that data is not lost by 
overfilling and also that the buffer does not run dry. 
However, this can result in a variable quality constant bit 
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rate stream. That is, with CBR there is no correlation 
between the transformer encoding rate and the type of video 
that is being received by the transformer. Thus, it is possible 
that as the buffer signals back to the transformer that it needs 

S to adjust the encoding rate, it will do so at a time that the 
video signal will be ill-served by the requested adjiistment 
so as to degrade the quality of the signal represented by the 
constant bit rate stream. Thus, employing this transport 
scheme is costly in terms of variable quality. Furthermore, 
there is a penalty in that there is no attempt to exploit any 
multiplexing gains that are possible in the original variable 
bit rate trafi&c. However, the advantage to this scheme is that 
the constant bit rate nature of this stream makes admission 
control to the network trivial. 

J 5 An unrestricted (or open-loop) VBR provides that the 
inherently bursty video traffic from the encoder is trans- 
ported over the real-time VBR service class. Since peak-to- 
me an ratios of the traffic can be high, there is a potential for 
multiplexing gain and the "effective" bandwidth needed may 

20 be less than that for CBR of the same quality. In this 
configuration the source rate itself does not adapt to the 
network's state. An example of an encoder in such a service 
could be obtained by modifying the encoder of FIG, lA to 
delete the feedback provided by line 15. For admission 

25 control of such sources it is necessary to provide an accurate 
source model and it is also necessary to police the sources 
to insure that they conform to the model. Due to this latter 
requirement, source models in practice are restricted to 
simple models such as the specification of peak rate, average 

30 rate and a maximum burst size (which can be policed using 
leaky buckets). Such a simple source model forces admis- 
sion control to be conservative since the lack of statistics 
regarding source behavior, necessitates conservative 
assumptions, to overcome errors in estimation/prediction. 

35 The use of the best-effort service for transport of com- 
pressed video requires unrestricted source adaptation as in 
the Internet N^deo Tools (such as VIC, NV) where the 
sources adapt to the rate offered by the network. This can be 
viewed as an extreme of a rate adaptive source in contrast to 

40 the opposite end of the spectrum, the unrestricted VBR 
service, where sources do not adapt to network conditions at 
all. Using a best-effort service, the quality can get unaccept- 
ably poor since there is no minimum rate guaranteed, 
A hybrid approach has also been considered. This hybrid 

45 can be referred to as renegotiated CBR (RCBR) which is a 
hybrid of the CBR and VBR approaches. The renegotiated 
CBR attempts to combine the simplicity of admission con- 
trol for CBR with the advantages of VBR, This is based on 
the observation that video traffic has fluctuations happening 

50 over both short time scales (less than typical buffer drain 
times) and long time scales, A component of multiplexing 
gain in unrestricted CBR is the buffer- less multiplexing gain 
(from the multiplexing gain across sources), RCBR simpli- 
fies network support for VBR video by accounting only for 

55 this gain, that is, it does not attempt to extract the gains from 
shared buffering in the network. An effective bandwidth also 
referred to as an effective bit rate is requested such that the 
source buffer can absorb short-term fluctuations without 
exceeding specified loss rales. The requested rate is then 

60 renegotiated when a change in the slow (long) time scale is 
detected. The network therefore sees sources with piece wise 
linear rates that can be transported as CBR streams. The 
scheme depends on distinguishing short-term fluctuations 
from long-term trend changes and the rate renegotiation 

65 involves signaling. Unfortunately, on present day systems 
this can reasonably be done only in intervals of at least a few 
tens, if not hundreds, of frames. Furthermore, it is not only 
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required that a trend change be detected, but also that at the 
beginning of such a change period an effective bandwidth 
valid over the slow time scale (on the order of seconds) be 
forecast. An algorithm for computing optimal rate requests 
for stored video is described in a paper entitled "RCBR: A S 
Simple and EfiBcient Service for Multiple Time Scale Traf- 
fic" by Grossglauser et ah, proceedings of the ACM SIG- 
COMM 1995 Conference, September 1995. However, a 
method to compute rate requests for real-time video is not 
given. A source initiated renegotiation necessarily implies 10 
that there is no mechanism for the network to inform sources 
of congestion abatement and newly available bandwidth. 
Hence, a source which adapts downward cannot use newly 
available bandwidth until the next renegotiation instant. 
Achieving low renegotiation blocking with RCBR (needed 15 
to control loss and frequent downward adaptations) requires 
careful engineering of the network and a good model for the 
distribution of source rates over the slow time scale. 

Having reviewed the features to these ATM service 
classes it is appropriate to consider how the needs of video 
transmission mesh with these services. Maintaining low 
overall delay is critical especially for interactive video. An 
explicit rate scheme, with appropriate switch rate allocation 
mechanisms, ensures that the aggregate rate of all of the 
sources sharing the resource remains below the resource 25 
capacity. 

Unlike data, transmitting entertainment quality video or 
video from teleconferencing applications requires a mini- 
mum bandwidth from the network to insure acceptable 
quality even in periods of congestion. Traditional best-effort 
services in data networks such as the current TCP/IP Internet 
have not provided such a minimum bandwidth while some 
of the service classes in ATM are designed to support such 
a minimum. 

It would be advantageous if there existed a scheme for the 
transmission of compressed video data that took advantage 
of a number of the more desirably features of the above 
known transport mechanisms. For instance, it would ben- 
eficial to provide a mechanism that preserves the simple call 
admission control feature of CBR while exploiting the 
inherent negotiation available in explicit rate schemes. 

SUMMARY OF THE INVENTION 

The present invention provides such an advantageous 45 
scheme for the transport of compressed video data. In 
accordance with the present invention a source adaptive rate 
encoder determines a desired rate and requests that the 
network provide or allocate such a rate to the source. The 
network then analyzes the request and reports back an 50 
allocated rate which is dependent upon the demand rate of 
the source, the demand rate of other sources and the overall 
bandwidth or channel capacity available at that time. Upon 
receiving notice of the allocated rate, the adaptive rate 
encoder then adjusts its encoding rate to match the allocated 55 
rate. 

The present invention takes advantage of a service 
referred to as Available Bit Rate (ABR) in ATM networks. 
In an embodiment of the present invention the encoder 
predicts needed rates over very short intervals and requests 60 
a rate of the network using a resource management cell 
provided in the ABR service scheme. The rate typically 
relates to the number of cells of bits which can be trans- 
mitted per unit of time. The network processes the request, 
allocating bandwidth among video sources in accordance 65 
with their demands and the bandwidth availability at each of 
the switches. The requesting video source is then advised of 
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the explicit rate permitted and the encoder then adjusts the 
encoding rate accordingly. 

The resource management cell in the ABR scheme allows 
for frequent renegotiation of the rate between the source and 
the network. In addition, ABR provides for allocating a 
minimum cell rate by allowing the source to request a 
minimum acceptable rate from the network. Since the 
admission control for ABR is simple, based on a minimum 
rate, the same simplicity as CBR for admission control *is 
available. By setting this rate equal to an effective bandwidth 
of the source, computed for a single source and using only 
a source buffer in the calculations, it is possible to operate 
in a VBR-like mode with few rate adaptations. However, 
there is room for more aggressive admission of additional 
streams, when rate adaptation takes care of the occasional 
situation when multiple streams simultaneously desire a 
high bandwidth. 

The present invention also provides for predicting the rate 
that the video source will need and hence should demand 
depending on the types of video, such as video 
teleconferences, or entertainment quality videos such as 
MPEG video. In a further improvement the present inven- 
tion smooths out the predicted rate by averaging the pre- 
dicted rate over a predetermined number of frames and then 
bases the demand to the network on this smoothed predicted 
need. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a known configuration for transmitting 
compressed video information. 

FIG. LA illustrates a known adaptable video encoder. 

FIG. 2 illustrates an embodiment of the present invention. 

FIG. 3 illustrates a data transfer operation from a source 
to a destination in the network of FIG. 2. 

FIG. 4 illustrates a timing diagram for understanding the 
operation of an embodiment of the present invention. 

FIG. 5 provides a flow chart describing operation of an 
embodiment of the present invention. 

FIGS. 6 A and 6B show graphical representations helpful 
for understanding the prediction of demand rates in accor- 
dance with the present invention. 

FIGS. 7A and 7B show block diagrams of embodiments 
of source modules for use with the present invention. 

DETAILED DESCRIPTION 

The present invention provides a new method and system 
for transporting compressed video that provides feedback 
control of the encoding rate. The present invention takes 
advantage of one of the classes of service offered by ATM 
networks, the Adjustable-Bit Rate (ABR) scheme. In accor- 
dance with this explicit rate mechanism, a video source 
supplies a Demand, a desirable cell rate, to the network. The 
network, in the form of the switches and links which 
transport the video data, allocates bandwidth (cell rate) to 
the video sources connected to the network in accordance 
with one of a selected number of different methods which 
are referred to below. Once the network has allocated 
bandwidth, a notice is provided back to the video source as 
to the explicit rate at which it is permitted to operate. Then, 
an adaptable rate video encoder receives the explicit rate 
information and adapts the video rate to conform to the 
explicit rate defined by the network. 

To enhance the overall quality of the video bit stream, 
allowing a more perfect match of encoding rates to the video 
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information from the source, the present invention also The implementations illustrated in FIGS. 7A and 7B are 

provides a mechanism for predicting demands to be made of provided only as examples and are not intended to be 

the network based on the character of the video information exhaustive descriptions of how the functionality of source 

which is to be encoded in the future. The demand operation element 200 could be apportioned between an encoder and 

can be enhanced by averaging the demands from the source S ATM interface. The network interface module (software 

over a given time period so as to smooth out the demands hardware) can provide feedback to the encoder as shown 

presented to the network whereby reducing some of the ^ ^IG. 2 for adjusting the encoding rate. In addition, the 

problems which could arise from the bursty nature of the mterf ace may contain its own buffer and in part rely 

video data M^on that buffer for purposes of controlhng the overall bit 

^ '. . , ^ . ^ . J - ^ f -.n rate from the video source to the network. In an encoder that 

BG. 5 IS a simple flow chart indicating the series of lO ^ ^^^^^^^ ^.^ ^^^^^ 

processes which would be undertaken in connection with ^^^^.^^ ^^^^^^^ .^-^^ 

controlhng the rate of encoding at the video source. In step tuuuu uj tj *-f 

™ .5 J- . ^if 1. J -j^u J- / The above has been a very broad general description of 

501 the video source predicts the bandwidth or encoding rate * ^ *u -nf f n • 

. . , ^ - c, . „ ^. ^^.j aspects of the present invention. The following sections 

which will be necessary for a near future collection of video ^ j • c * r *u 

, , . . Ji u J- *• *u i«; provide more descnptions of component portions of the 

data. Having generated such a prediction, the source gener- is j . • , j . -i j 

L J j.u . j/ * .1- • overall system and method mcluding a more detailed 

ates a bandwidth request and transmits it to the network in , • r *u -i n u*. . • j • c 

ct^« <ft'> T-k^ «ot„,^.t, ™^^oo»o tui^ r^«..oo* t« ^oto, description of the available bit rate service, a descnption of 

step 5U2. 1 ne network then processes this request to deter- ^ ^ . r c j. i . , . • !, 

. .f-L.u J uij the operation of the feedback control mechanism, a descrip- 

mine an explicit rate at which the video source should * u • j* j- * » j 

transmit ii, step 503 and sends that expUdt rate back to the f °" of the techniques used to predict a source s demand to 

.J . ^ . ™ J . .V -J . on the network and a description of how the network responds 

video source in step 504. The encoder at the video source is -^^ ^ ^ 

then adjusted to reflect the rate allocated to the video source 

by the network in step 505. The process is then repeated. 

™« -11 . ^ ... • 1 The Available Bit Rate (ABR) service is initially defined 

FIG. 2 illustrates one embodiment for implementing the ... , ^ , ^ . *u . 

, r^,^ J • r m the ATM Forum to support applications that require 

present invention. An encoder 210 receives video informa- u * fP * • /at-x* a* * 

f. , . jj-j A^i-^_r J 25 best-eftort service (ATM Forum Tramc Management 

tion and produces encoded video. A network mterf ace mod- „ vc \ v *• j * i i 

1 • J I . .1 J '^-■ft J Specmcation). These appucations desire a low loss rate, 

ule 220 IS connected between the encoder 210 and the JT • -l i .. *l * *u i j r 

1 -^irt A • T-i.-. ^ *i- * 1 There is the possibility that the demands of the sources 

network 230. As m FIG. 1 the network can comprise a j ai^l ^ 

, - , „ 1 J /^-.-i . r« exceed the resource capacity. Although no assurances are 

number of switches, tor example 231, 232, and 233, etc. Ihe , - • * • - i j i r jl i * i 

. , - J , u . I- -^u »u . made of mamtammg low delay or jitter, a feedback control 

interface module has a two-way connection with the net- i -.u ** . * • * • n j ui 

J • r . • . *u * 1 / 30 algorithm attempts to maintain small queues and feasible 

work m that it sends information out into the network (as , . . . r ■ j- -j i * • *u 

*4ui- A ' • e *• uip transmission rates for mdividual sources, that IS, the aggre- 

represented by bne 221) and receives information back from , ^ * ^ n r *u *i 

^ , / \ ^^^\ r™ - • .-11 gate transmission rate of all of the currently active sources 

the network (as represented by line 222). This IS particularly ■ • i- i j * ^ *u i- i % tt, Aon 

, , \, r . . / ^ 1 utilizing a link does not exceed the hnk capacity. The ABR 

cntical to the notion of receivmg from the network a . * , . , , c • • u j -j^i. 

J . - 1- * ^ 1. .1. .1 -11 service also admits to the notion of a minimum bandwidth 

designation of the explicit' rate which the network will n * a^u u j • • * t 

. , . . J u J J 35 allocation for a source. Although an admission control 

permit the video source (as represented by the encoder and , f 

- J -J J . . ^ 1 ^ mechamsm has not been specified one can be defined that IS 

mterface module) to provide video data to the network. The ^^«oo„,ot;„« 

. - . ,^ , J ^ * relatively simple and conservative, 

mterface module 220 generates and transmits the request , . ^x^„ . . « 

(Demand) to the network based on the prediction made as to 1°, ^^^"^^ ""^.'^^T. I .TT. ^ 

the rate needed for future video information. The interface ^ resource management CRM) cell to probe the state of 

module then receives the feedback mformation from the ^ n^!,^"*- specifically a source can specify a 

network regarding the allocated rate as represented by line "^em-md or desired transnait rate (typic^ly in teraas of a cell 

222. Hie entire source element 200, including the encoder JfJf ) '° transmitted RM cell, m a field identified as the 

and the interface module, adjusts the rate of information (or exphcit rate) field The source also identifies to the 

from the interface module into the network thereby control- "'''y or op^Mit^ rate (CCR- 

ling the rate to be consistent with the explicit rate permitted 'i"'^"' ""^^ ^he switches in the network then compute 

K., ^^f..r^.^. the rate that they will allocate to each source in accordance 

by the network. . , , , , . , , „ ■ . ■ , 

^ . ^ , with a prescribed bandwidth allocation algorithm. Examples 

Examples of possible implementations of the source ele- ^^^^^^ algorithms are discussed in more detail in one of the 

ment 200 are shown m greater detail in FIGS. 7A and 7B. following subsections. Onc« the network switch computes 

In the first example of FIG. 7A the source element uses an 50 the allowed rate, with whichever algorithm is selected, then 

already existing adaptive encoder and couples it to a net- this allowed or allocated rate is overwritten into the ER field 

work interface that may be a combination of hardware and of the RM cell if the allowed rate is lower than what was in 

software with a buffer for receiving encoded data from the the received RM cell. That is, if the system will only allow 

encoder. In this embodiment the network interface software a cell rate less than what was demanded by the source that 

can: perforai the prediction of the desired rate; create the 55 cell rate will be written into the ER-field replacing the cell 

network probe, a resource management ceU that, contains rate in the received ER field. As the RM cell progresses from 

the requested or demand rate; receive the allowed rate and the source to the destination the ER field may be changed 

adapt the output rate using the buffer that receives the one or more times as the various switches through which the 

encoded data. information is passed calculate their own allocation of 

In a second example in FIG. 7B a more standard or 60 bandwidth based on the traffic from different sources that 
generic ATM network (consisting of hardware and software) flow through that switch. Thus, as the RM cell progresses 
is used with a more customized encoder that incorporates the from the source to the destination, the ER-field value reflects 
prediction capability and which absorbs the buffer for adapt- the smallest rate allocated by any of the switches in the path 
ing the rate to the allocated rate. In this circumstance the for the video. This smallest rate is indicative of the conges- 
encoder will provide the rate request to the module which, 65 tion in the path. On reaching its destination, the RM cell is 
in turn, will insert the request in the appropriate network returned to the source. Then, in accordance with the present 
probe. invention, the transmit rate can be adjusted based on the 
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ER-field value in the returned RM cell. The way in which the lation. These correlations are typically very high for tele- 
encoder adapts to the returned allocated rate is described in conference sources with p-0.98. This high correlation 
further detail in one of the following subsections. makes fairly accurate short term forecasting feasible. Avery 
The goal of the explicit rate-based feedback control simple forecasting rule is: X„.;t->v«P*(X„-/^) where p is the 
algorithm is to respond to incipient congestion and to 5 correlation coefficient, and pi, the mean number of cells per 
allocate rates to the competing sources in a fair manner, frame, is computed on-line. An accurate model is the DAR 
while insuring that the capacity of the network is not (1) (Discrete Auto-regressive) model which is a Markov 
exceeded. chain determined by three parameters: the mean, variance. 
Predicting a Demand for the Network P- transition matrix is computed as: 
Before describing detailed examples of predictive P-pl+{i-p)Q (Eq. 3) 
schemes, a few issues must be appreciated. First, as 

described with respect to FIGS. 7A and 7B the prediction where p is the auto -correlation coefficient, I is the identity 

operation can be done in either the interface module or the matrix, and each row of Q consists of the negative binomial 

encoder or could be otherwise provided for in the source (or gamma) probabilities (53- . . . ,f/f,Fj^) where Fj^I.;^ffj, 

element 200 of FIG. 2. Second, the following detailed and K is the peak rate. The DAR(l) model matches the 

descriptions of predictive techniques arc merely offered as auto-correlation of the data over approximately a hundred 

examples of how the system could predict the demand frame lags. This match is more than sufiBcient for the 

needs. Such predictions have been used in other contexts. inventors' purposes, since the forecasting horizon is a few 

But, the present inventors were the first to appreciate the round-trip times which correspond to only three of four 

usefulness of predictions in connection with generating rate frame lags at most. Knowing the mean, variance and lag-1 

requests in the system of the present invention. correlation of the source, forecasts can be made using the 

In connection with predicting the demand for the network DAR(l) model given only the number of bits in the current 

it is important to recognize that there are various classes of frame. The DAR(1) model can be used with any marginal 

video sources. For instance, there are sources with low to distribution and this was used to model entertainment and 
moderate activity such as video teleconference sources. In ^ MPEG-2 coded video sequences with marginal distributions 

these sources the video image may change infrequenUy and which are not gamma distributed. (This is described, for 

the amount of change at any one time is likely to be small example, in "Source Models of Broadcast-Video Traffic", 

by comparison to the entirety of the image. Alternatively, Heyman et al., IEEE/ACM Transactions on Networking, 

there are active sources such as sports telecasts and movies. Vol. 4, No. 3. pp. 301-317 June 1996). For teleconference 

In these sources, the image changes frequently and the sequences, since the marginal distributions are gamma dis- 

amount of change in an image can be dramatic. In connec- tributed this gencraHty is not necessary. Moreover, the 

tion with describing a technique for predicting the needs of DAR(l) model has "flat spots'' which make its sample paths 

the source in terms of bandwidth allocation, the inventors "look" different from those of the data when conipansons 

have focused on models which characterize the video input are made for a single source (for multiplexed data sources 

in terms of the number of cells per frame of video. Video they are indistinguishable). Though these flat spots may not 

source models were formulated by examining long traces of affect our results, for the teleconferences the inventors used 

recorded traffic giving the number of cells per frame for tens a statistical model more specialized for modelmg accurately 

of thousands of frames. The formulated models match the the short-term fluctuations of single teleconference sources, 

marginal distributions of the data and match the auto- A model, called Gamma-Beta Autoregressive or GEAR 

correlation to a certain degree. (1) °5odcl, has been proposed. Like the DAR(l) model, the 

Models for Low to Moderate Aaivity GBAR{1) model is also a three parameter model requiring 

In traffic for low to moderate activity video, such as video only knowledge of the mean variance and 1-lag correlation 

, , c - Ti -.£1 Tro^n 1- A' of the source. It rehes on the observation that video tele- 

teleconferencmg using H.261 or H. 261 -like coding as ^ , * i j- . -i j 

J -u J • .if Oi-.TVr A r ™ J 1 conferences have gamma marginal distributions and expo- 

descnbed m the CCITT recommendation, models were ^ ^ ■ ♦ *i c u * mn 
c , . J L - - J * J J J • 1 ^ nentially decaying auto-correlations up to lags of about 100 

formulated by examming data recorded during several „ ^^ r^ r.^ ji j 

• . -J * 1 c -ru * «: ™ ~i 1 1 1 frames. The main features of the model arc summarized 

thirty-minute video teleconferences. The traffic models look , , . j • r ^- j i 

similar despite the sequences differing in the details of the ^'^ "» "''.•^'^Tf h"^ T ■ k, 

coding scheme. The inventors discovered that for the video .V" » ^^^^^ distributed random variable 

teleconference models the number of cells per frame can be shape parameter s and scale parameter k.Ul Be(t r) 

J 1 J . , rm. ■ 1 J- * u denote a beta distnbuted random variable. The density 

modeled by a stationary process. The margmal distnbutioo ^ r r . j- . l • • l 

e v f 11 c r 11 J- 4 u function of the beta distribution IS given by 

of the number of cells per frame follows a gamma distnbu- ^ ^ 

tion (negative binomial if a discrete distribution is used) and 

so the number of cells per frame is given by /^{x) = ^^,1^^^^^^ -x)'~\t.r>-i 

55 

^^'^ " r{s) ^ The GBAR(l) model uses the following facts: (1) The sum 

of independent Ga(s, X) and Ga(q, X) random variables is a 
Ga(s+q, X) random variable, (2) The product of independent 

where r(s) is the gamma function defined as g^^^^ ^^(g^ random variables is a Ga(t, X) random 

variable. The forecasting rule for the GBAR(l) model is 

ru) = J" r^e-'dr given by: 

^„^^^~i^B„ (Eq. 5) 

The parameters s and X are called the shape and scale 65 Since for video teleconferences it is desirable to have the 

parameters respectively and these can be obtained from the distribution of X„ (and naturally X„.i) to be Ga(s, X) (the 

mean and variance of the source. Let p be the lag-1 corre- shape and scale parameters being obtained from the empiri- 
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cal mean and variances as was done for the DAR model), 1 
A„ is picked to be a Be(t, s-t) random variable and B„ to be 
a Ga(s-t, K) random variable. It may be easily verified from 
Equations (4) and (5) that when X„.j, A„ and B„ are mutually 
independent, X„ is Ga(s, X) distributed as desired. Also, the 
lag-k auto -correlation function is given by p(k)=(t/s)*. Using 
this t is determined since we know p-p(l), and s (from the 
mean and variance of the data), the forecasting computation 
is simple: given X„.j multiply it by B„ a sample from an 
independent beta distributed random variable and then add 
A„ drawn from a gamma distribution. Both disu-ibutions 
have parameters which need to be computed only once from 
the mean, variance and 1-lag correlation of the teleconfer- 
ence sequence of interest. 

For four video teleconferences, the GBAR(l) process was 
used for short-term prediction of the number of cells per 
frame given the number of cells per frame for the current 
frame. The mean, variance and 1-lag correlation needed for 
the predictions is given for each of the sequences in Table 1 
below. 



TABLE 1 







Mean 




Lag-1 


Sequence 


Bylcs/CcU 


cells/frame 


Variance 


Conclation 


A 


14 


1506 


262861.29 


.981 


B 


46 


104 


88Z 09 


.984 


C 


64 


130 


5535.36 


.985 


D 


64 


170 


11577.76 


.970 



The Active Source Model 

Active sources such as those involved in providing video 
entertainment such as sports telecasts and movies are gen- 
erally refened to as MPEG encoded, the basics of which are 
described in "MPEG Coding for Variable Bit Rate Video 
Transmission" by Pancha et al, IEEE Communications 
Magazine, pages 54 to 66, May 1994. A few important 
aspects of this coding are of interest to understand the source 
model. There are three picture (frame) types called I, B, P 
frames, which appear repetitively in the following fifteen 
frame pattern: IBBTBBTBBTBBTBB. This is caUed 
a group of pictures (GOP). The GOP length can vary and the 
length of fifteen used here is not universal. The P frames are 
predicted using previous I and P anchor frames. The B 
frames are predicted in both backward and forward direc- 
tions by using I or P frames. The I frames are coded in the 
intraframe mode, so they have less compression than the B 
and P frames. A histogram and auto-correlation of the B 
frames of the data is shown in FIGS. 6 A and 6B. B frames 
arc shown because they are the most frequently occurring 
frames in the studied sequence. The other frames have 
similar characteristics, in particular the high correlations. 
This is described in a paper entitled "Statistical analysis of 
MPEG 2-coated video traflBc" by Heyman et al.. Proceed- 
ings of Symposium on Multimedia Communications and 
Video Coding: A Celebration of the Centennial of Marconi's 
Invention of Radio Transmission, October 1995. The long 
right tail in the histogram shows that the bit rate is quite 
bursty. Also from the plot of auto-correlation it is clear that 
the short- terai correlations are very high — a fact to be 
exploited for forecasting. The forecasting can be done using 
the source model developed in the Heyman article. The I 
frames have a log-normal distribution and the auto correla- 
tion of I frames decays geometrically and has the form 
0.823* where K is the lag. Consequently, in video 
teleconferences, I frames can be modeled by a Markov chain 
with a DAR (1) transition matrix similar to that used for a 
video teleconference. The matrix Q in this case has rows 
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which are discretizations of the log-normal distribution 
instead of a negative binomial. Excluding some outliers, the 
B and P frames also have log-normal distributions (the 
distributions are not identical since their mean and variances 

5 are different). The correlation between successive B frames 
is very high (0.90). ITie Bj frames can be modeled by a DAR 
(1) process with PeO.8 and log-normal marginals succeeding 
B and P frames are correlated (0.77). These correlated 
random pairs can be generated using TES which is described 

10 in an article "TES: A Class of Methods for Generating Auto 
Correlated Uniform Variates" by Melemed, Orsa Journal on 
Computing, 3, pages 317 to 326, 1991. 

Having considered the active and inactive sources and 
their characteristics, it is possible to thus model and predict 

15 what the cell rate needs will be for an encoder based on the 
types of video to be transmitted. 
Other Prediction Considerations 

The demand for the video source must be predicted 
sufficiently ahead of time so that feedback from the network 

20 arrives in time for providing the rate information to the video 
encoder to encode the next frame. That is, it is important that 
the prediction as to a particular part of the video be done far 
enough in advance so that the network processes the demand 
and sends back an allocated rate with the appropriate timing 

25 to execute that rate on the video which formed the basis for 
the prediction for the demand. Furthermore, the rate returned 
(ER) needs to be adequate to transmit the subsequent video 
frame(s) (until the next feedback is received) without sig- 
nificant degradation in quality or unacceptable delay. 

30 If one were to take a look at a time line for operation as 
illustrated in FIG. 4, one would see that a rate request would 
be made at time t based on the prediction of the frame's 
requirement at time t+T. T must take into account a number 
of factors such as the round trip delay of the request through 

35 the network (RTT), the time for the encoder itself to adapt 
to a new rate (E), frame time (F) and the time taken to 
packetize the data and hand it down to the ATM adaptation 
layer (6), Thus, T is represented as equal to RTT+e+F+6. It 
is presumed that the encoding of the frame also takes a frame 

40 time (F). Frame time F is the time it takes to transmit the bits 
in the frame at the "ideal rate". This is 33 msecs for a 30 
frames/second system. All of the bits of a frame should go 
out before the next frame is generated F-1 /(number of 
frames per second). 

45 There are several issues with just using the straightfor- 
ward prediction of a single frame size at F+RTT later. Since 
there may be considerable variation in the frame sizes, the 
time for looking ahead in the prediction has to be precise. 
For example, if the response from the network comes too 

50 late for the coder it would mean that encoding would be 
done according to an earlier rate relating to a previous frame. 
If the response comes too early, the rate may be superseded 
by a subsequent rate feedback such that coding will be at a 
rate more suitable for a frame to be transmitted at a later 

55 time. Furthermore, the rate received from the network for 
this frame (in time for it to be encoded at RTT+e) is 
implicitly assumed to continue to remain available until 
t+RTT+e+2F+8 when the frame transmission is completed. 
If the rates received in subsequent RM cells are different and 

60 lower, this may lead to the frame being delayed, because of 
the lower rate. However, this delay may be acceptable if the 
minimum cell rate (MCR) is large enough. 

Knowing the RTT reliably for a connection may also be 
difficult, as it comprises propagation delays, queuing delays 

65 and processing delays at switches (which may be small) and 
the source and destination end-systems (which may be 
larger). Therefore, to limit the sensitivity in precisely match- 
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ing the prediction of a frame rate at the time when feedback 
is returned, a smoothing technique is chosen. The require- 
ments of several frames from the next frame to the frame 
that may be sent 1 RTT later (based on an approximate 
estimate of RTT) are predicted. The average rate for these 
frames is then calculated. This average rate can then be used 
as the demand requested of the network. Specifically, it 
would be appropriate then to predict the requirements of N 
frames in advance (as a moving window), and compute a 
demand (placed at time t) based on the average rate for these 
N frames. In one example, it might be appropriate to select 
a window as large as five frames. 

Having discussed the techniques for predicting a demand 
including the timing for such a prediction and the smoothing 
out of the request or demand based on predictions over a 
window of frames, it is appropriate to consider how the 
network treats the demand and how the encoder adapts to the 
response from the network. 

Network Response to Demand 

As described above, each source periodically transmits a 
special resource management (RM) cell to probe the state of 
the network. This is illustrated in FIG. 3. Each switch, 
identified as elements 315, 316, and 317, identifies and 
conveys its state of congestion as well as additional rate 
information in its treatment of the RM cell. The source, 
having predicted a demand as described above, sets a desired 
transmit rate in each transmitted RM cell. The cell also 
includes information identifying the actual cell rate. When 
an RM cell is transmitted, the ER-field is set to Max 
(Demand, ACR). RM cells are periodically transmitted once 
every Nrm data cells, for example Nrm may equal 32. Thus, 
the overhead for carrying the probe cells is bounded while 
still having the responsive control scheme. Each of the 
switches then computes the rate that they may allocate to 
each source. A switch will overwrite an allocated rate in the 
ER field if the computed rate is lower than what was in the 
received RM cell. Thus, if switch 311 can only allocate a cell 
rate that is lower than that requested, then the allocated rate 
is written over the requested rate (ER field) in the RM cell 
and included in the message as it travels downstream to 
switch 312. Switch 312 then operates on this modified RM 
cell. As the RM cell progresses from the source to 
destination, the ER field value reflects the smallest rate 
allocated by any of the switches in the path from the source 
to the destination. On reaching its destination the RM cell is 
returned to the source which can then set its transmit rate 
based on the ER field value as will be described below. 

The goal of the explicit rate-based feedback control 
algorithm is to respond to incipient congestion and to 
allocate rates to the competing sources in a fair manner, 
while insuring that the capacity of the network is not 
exceeded. 

There are several switch algorithms proposed for com- 
puting the rate to be allocated to a source. Switches compute 
an allocated rate for each source I based on its requested rate 
(value in the ER-field) A,- i-1, 2, . . n. Sources are classified 
as being in a "satisfied" set S or in a "bottle necked" set B. 
The capacity C of the link is allocated to bottled necked 
sources as 

y (Eq. 6) 

Sources in the satisfied set S are allocated their requested 
rate A,.. To keep the dynamics of the switch policy simple it 
is possible to implement a straight forward version of a 
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max-min computation broadly described in "Congestion 
Avoidance in Computer Networks with a Connectionless 
Network Layer. IV: A Selective Binary Feedback Scheme 
for General Topologies" by Ramakrishnan et al, DEC-TR- 
5 510, Digital Equipment Corporation 1987. 

The source maintains a currently allowed rate ACR which 
is the rate at which queued cells are transmitted out of the 
source -network interface. Sources maintain a demand (for 
data sources this may be the outgoing links rate), used for 
10 requesting a rate for the network. When an RM cell returns 
with an allocated rate ER, the source's allowed rate is 
changed as follows: 

if ACR^ER, 

ACR=max (min (ER, demand), MCR) 

15 else ACR-max (min {ACR+(RIFxPCR), ER}, MCR). 
A network indication to decrease the rate takes effect 
immediately. However, when the allocated rate ER returned 
is higher than the ACR it increases in additive steps of RIF 
X PGR where RIF is a rate increase factor that is a negotiated 

20 parameter and PGR is the peak cell rate for the connection. 
A large RIF (approximately 1 .0) results in converging to a 
returned ER quickly. The trade off is the potential for some 
transient overload on the network. To keep the queue build- 
up small, RIF may be chosen to be small instead (e.g. Vcw). 

25 ACR always remains above the minimum cell rate MGR. 
In the known max-min fairness algorithm the switch 
receives the ER fields from the sources for which it is 
carrying video information and determines as a first matter, 
based on the gross number of sources an average per source 

30 bit rate (or cell rate) available. For instance, if the switch 
capacity is G and the number of sources is four then the 
average per source bit rate would be G/4. Then, the explicit 
rates of the respective sources would be compared to the 
average bit rate. For any source that already had an explicit 

35 bit rate or cell rate lower than the average per source rate 
those sources would be treated as satisfied sources and 
would be allocated their full explicit bit rate. Then, the sum 
of the bit rates allocated to the satisfied sources would be 
subtracted from the total capacity to determine a remainder 

40 capacity. The remainder capacity would then be used to 
calculate yet another average allocation per source based 
upon the number of unsatisfied sources remaining. The 
process described above for comparing requested rates to 
average allocations would be repeated and the process 

45 would continue until only unsatisfied sources remain. At that 
time the unsatisfied sources would each be allocated some 
value that would be less than the previously indicated 
exphcit rate. The granted allocation would then be written 
into the RM cell over the exphcit rate (ER) field and sent 

50 downstream to the next switch to be used in the calculation 
at that switch. That second switch would then use that 
information in the ER field in the same way that the first 
switch used information in that field. 

This is one possible method for calculating an allocation 

55 of resources at a switch given the requests from a number of 
sources and the channel capacity available at the switch. 
Another technique for calculating allocated rates is 
described in co-pending application Ser. No. 08/825,995 
filed on the same day as this application and entitled A 

60 Method for Fair Allocation of Bandwidth the disclosure of 
which is incorporated by reference herein, now issued as 
U.S. Pat. No. 5,946,324. 

The distributed rate allocation algorithm that seeks to 
achieve max-min fairness performs this by an iterative 

65 process. There is a "global iteration" achieved by RM cells 
flowing from the source to destination and back, collecting 
the rate allocation information for the flow. Further, there is 
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a "local iteration" at each switch link to determine the 
allocation to each of the flows sharing that link. 

At the first step of the global iteration, the allocation of all 
the flows sharing the first-level (tightest) bottleneck is 
determined. Subsequently, in each of the next steps of the 
global iteration, the allocation of flows sharing the next- 
level (nexl-tightesl) bottlenecks is determined, progressing 
from one bottleneck level to the next, until there is an 
allocation of the rates to the flows sharing the K''*-level 
(loosest) bottleneck in the network. It is known that an upper 
bound on convergence time of such distributed algorithms 
determining a max-min fair allocation is K * RTT, where 
RTT is the maximum round-trip delay for control informa- 
tion to propagate from the source through the network to the 
destination, and back to the source; and K is the number of 
different bottleneck rates. (See "Time Scale Analysis and 
Scalability Issues for Explicit Rate Allocation in ATM 
Networks," Chamy el al., IEEE/ACM Transactions on 
Networking, Vol. 4, No. 4, August 1996). There may be 
significant queuing delays for RM cells, as well as propa- 
gation delays (e.g., in a wide-area network), which contrib- 
ute to RTT. As a result of a richly connected network, each 
link having diverse numbers of flows sharing them or with 
sources having different demands, the number of distinct 
rates, Kmay be large as well. Thus, the time to converge to 
a final rate allocation for all the flows, once the demands 
have stabilized, may be larger than a frame time. The source 
rate adaptation policy needs to be cognizant of this, as we 
discuss below. 

Having described the allocation of rates in accordance 
with the rates demanded, it is now appropriate to consider 
how the encoder adapts to the allocated rates. 

Adapting the Source Rate to Feedback 

After the Demand for a rate is made to the network based 
on the prediction, the source now has to adapt it's encoding 
rate to the permitted or allocated rate. There are several 
increasingly sophisticated options available here for adapt- 
ing the encoder's quantization level to the allowed trans- 
mission rate ACR at the ATM layer. 

1. Directly use the instantaneous ACR as the coder's rate 
to encode the next frame. 

2. Use information on the occupancy of the source buffer, 
between the coder and the ATM layer, to modify the encod- 
ing rate. 

3. Use a combination of the source buffer and the recent 
history of ACR returned to adapt the coder's rate. 

Using the first option would imply directly using the 
feedback information from the network to adjust the coding 
rate for the next frame. There is an immediate connection 
between the feedback from the network to the coder. This 
works well if the estimate of the feedback delay is perfect 
and also if the network returns an ER value that is very close 
to the Demanded rate. Neither of these are likely. The source 
should adapt its rate to changing conditions in the network. 
Moreover, it is difficult to estimate the feedback delay. 
Another important problem is that during the transient 
convergence period when the network is attempting to 
converge to the final weighted max-min rate, ER and hence 
ACR for the source is continually changing. Using a RIF 
value that limits the step-size with which the source may 
build up its ACR towards the returned ER also makes this 
matching quite difficult. It is also believed that the poten- 
tially rapid fluctuations of the coding rate adversely impacts 
the quality of the video. 

The second option takes advantage of local source buffer 
shown in FIGS. 7A and 7B as being part of either the 
encoder or the ATM Network interface, between the encoder 
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and the ATM layer to "integrate" the effects of both the 
differences between the coder's desired rate and the feed- 
back rate. The buffer also smooths out some of the errors in 
the estimation of the feedback delay. The buffer isolates the 
network's rate feedback from the encoder to a certain extent. 
So, the encoder's rate is based on the local buffer occupancy 
Boccy whose level should be maintained between a low 
threshold Q,„^ and a high threshold 0^^^/,. A rate reduction 
is provided, below the nominal rate the coder needs for the 
best quality (Rj), that is a linear function of the buffer 
occupancy in the range (Q/^wj Ohigh) average encoder 



(Eq. 7) 



While in principle, this does serve the function of smoothing 
the encoding rate allowed, it completely isolates the encoder 
from any drastic deviation of the network's feedback. As a 
20 result, large differences between "k^^g and ER may lead to 
unacceptable queue build-up locally at the source, resulting 
in either exceeding our delay targets or loss locally from the 
source buffer. 

The encoder's adaptation is enhanced to also account for 
the currently allowed source transmission rale, ACR, in the 
third approach. The deviations in the ACR help modify the 
encoder rate, while ensuring it is over a long enough time 
scale that the encoder's rate does not track the transients in 
convergence of rate allocation mechanism, for example. 

Knowing the requirements of the frame to be transmitted 
t+RTT+e+F+8 in the future, the source encoding rate (the 
quantization level), is computed as a function of both the 
average ACR and the predicted source buffer occupancy 
above a specified buffer set-point. The encoder's target rate 
is: 



35 



(Bt-f -SETP0INT)\\ 
limehonzon \\ 



(Eq. 8) 
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Here, Rj- is the required "nominal" (at the best quality) 
rate for a frame whose transmission time starts at time T, and 
By..^ is the predicted buffer size at the time the encoder is 
given the rate to code the frame, and SETPOINT is the 
desired buffer setpoint at the local source buffer, a is a small 
gain factor. The time_Jiorizon is the interval over which the 
attempt is made to bring the predicted buffer Bj-.^ down to 
the level of the SETPOINT. The time horizon is typicaUy of 
the order of a few frame times (chosen to be 5), so that the 
delay for a frame is not adversely affected. The constraint for 
choosing the buffer SETPOINT is that the contribution to the 
delay by the source buffer is not excessive. Similarly, 
ACR^vG is also computed over an interval of a few times 
(«5 frame times). 

It is anticipated that using an estimate based on the source 
buffer occupancy reduces the dependency on a prediction of 
the rate required at a precise time in the future. The source 
buffer makes it possible to smooth the differences between 
the rate requested and the rate received from the network. 

A minimum rate being allocated to the video connection 
(negotiated through admission control al call set up) is also 
important. The minimum rate may be based on knowledge 
of the video source's characteristics, that may be available 
a priori based on the type of video (e.g., teleconferencing, 
entertainment video), and the minimum acceptable quality 
for the user. 

Furthermore, it is anticipated that the system should be 
able to re-adjust the Minimum Cell Rate (MCR) when that 
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rate was incorrectly estimated at the beginning of the 
connection. One indication that MCR was set too low would 
be that the quality of the video has suffered when the source 
has been persistently allocated a rate corresponding to the 
MCR. Thus, the system would be enhanced if MCR was 
negotiated in response to selected trigger events, such as: 

a) if there is a loss of frames that degrades quality; 

b) if a difference between a "desired" high quality, high 
quantization factor video's rate and the network's allo- 
cated rate is large, and if it is frequently like that; and/or 

c) if the source buffer often runs at or close to the 
threshold where there is too much delay in the source 
buffer that causes delay targets (especially critical for 
interactive use) to be violated. 

Renegotiation of MCR triggers a fresh admission control 
decision and seeks to ensure a higher MCR. The likelihood 
is that as other connections are turned off the effect of the 
renegotiated MCR will be that the resource will not admit 
other new sources. Thus, MCR can play an important role in 
establishing baseline quality and in establishing a cut-off 
point for admitting new sources to share a resource. 

One of the issues that arises with using the source 
adaptation policies described is that the encoder's rate may 
be altered frequently, thus resulting in impairment of the 
user perceived quaUty of the resulting video. Another is that 
the amount of time taken by the allocation mechanism to 
converge to the assigned fair rate may be significant. As was 
observed earlier, it has been shown that it takes a period of 
RTT per distinct rate in the eventual rate vector for all of the 
source rates to converge on their final rates. In fact, this is 
with the source rates immediately tracking the ER value in 
the returned RM cell because RIF was set to 1 . When the rate 
increase factor, RIF, is smaller than 1, the convergence time 
is increased further due to the time it takes for the source rate 
to build up to its final value. 

For both of these reasons, it is desirable to use a longer 
averaging interval as well as reduce the frequency with 
which the source demand and the encoder's rate are modi- 
fied. It may be desirable to impose a "damping fiincfion" on 
the frequency of modification of these two values. These of 
course, depend on how much source delay can be tolerated. 
A constraint to be used as a rule of thumb is that the end-end 
delay should not be greater than about 200 to 300 millisec- 
onds per frame. 

The choice of the size of the moving window N for 
averaging the demand also depends on the coding scheme 
used (e.g., H.261 for video teleconferencing; MPEG for 
entertainment video). Using an averaging interval that is 
larger than a frame time is desirable. For example, using an 
average over several frames, such as a GOP for MPEG may 
be appropriate. 

A final note on implementation is that it has been assumed 
for the above examples that the network uses a separate 
queue for the admission-controlled flows such as these 
compressed video flows, isolated from data flows that may 
not be admission controlled. As a result, the service disci- 
pline at these queues needs to serve these queues in propor- 
tion to the rates aflocaied to each of these classes, within a 
reasonable time granularity. Admission control may be quite 
simple, based on the minimum cell rate, MCR, requested at 
connection setup time. 

CONCLUSION 

A particular embodiment for providing predicted 
demands to a network, calculating allocation rates based on 
the predicted demands, feeding back the allocation rates and 
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adapting the encoder rates based on the allocated rate has 
been described above in connection with an ATM network of 
the ABR variety. The general concepts of the present 
invention, namely the prediction of an encoding rate, the 

5 allocation and feedback, and the adaptation can be per- 
formed using different networks. Different structures for 
providing the adaptation (such as a differently structured 
network interface module) or different predictive techniques 
for determining a demand rate could be utilized. 

10 What is claimed is: 

1. A method for transporting compressed video from a 
source to a destination over an Asynchronous Transfer Mode 
network, the method comprising the steps of: 

a. predicting bandwidth needs of the source, said prcdict- 
15 ing including estimating a needed bandwidth based on 

a prediction of size of frames over a pre-determined 
period of time; 

b. requesting, by periodically transmitting a resource 
management cell to the network, that the network 

20 provide bandwidth to the source commensurate with 
the source's predicted need; 

c. receiving a grant of some bandwidth to the source equal 
to or less than that requested; and 

d. adapting an output rate of the source referring to the 
25 amoimt of bandwidth granted to the source in step c. 

2. The method of claim 1 wherein said step of predicting 
bandwidth further comprises determining an average band- 
width requirement based on a predetermined number of 
predictions of the size of frames. 

30 3. The method of claim 1 wherein said step of granting 
comprises the substeps of: 

receiving from each of a plurality of sources a requested 
fate; 

calculating an allocable rate for each source in depen- 
dence upon requested rates received; and 

for those sources for whom the network cannot satisfy the 
requested rate modifying a message to those sources to 
include notification of an allocable rate. 

4. The method of claim 1 wherein said step of adapting 
^ comprises the substeps of: 

receiving at a source module a network notification of an 

allocated bandwidth; and 
said source module adjusting an output of compressed 
45 video data in accordance with the received notification. 

5. The method of claim 4 wherein said source module 
includes an encoder, and said step of adjusting includes 
modifying an encoding rate of said encoder. 

6. The method of claim 1 further comprising the step of: 
50 negotiating a minimum bandwidth for the video source at 

a time of initializing communication from the video 
source. 

7. The method of claim 6 comprising the further step of 
renegotiating the minimum bandwidth if the difference 

55 between a requested bandwidth and the allocated bandwidth 
satisfies a predetermined criterion. 

8. A method for transporting video from a source to a 
destination over an Asynchronous Transfer Mode (ATM) 
Network, comprising the steps of: 

60 periodicaUy predicting a bandwidth need of the video 
source, said predicting including estimating a needed 
bandwidth based on a prediction of size of frames over 
a pre-determined period of time; 
transmitting a resource management cell to the A1"M 

65 Network, said resource management cell including a 
bandwidth request based on the predicted bandwidth 
need; 



07/09/2004, EAST Version: 1.4.1 



us 6,2( 

17 

allocating bandwidth to the video source equal lo or less 

than said bandwidth request; and 
adapting an output rate of the video source in accordance 

with bandwidth allocated to the source. 

9. The method of claim 8 wherein said step of predicting 
bandwidth further comprises determining an average band- 
width requirement based on a predetermined number of 
predictions of the size of frames. 

10. The method of claim 8 wherein said step of granting 
comprises the substeps of: 

receiving from each of a plurality of sources a requested 
rate; 

calculating an allocable rate for each source in depen- 
dence upon requested rates received; and 

for those sources for whom the network cannot satisfy the 
requested rate modifying the resource management cell 
lo include notification of an allocable rate. 

11. A method for establishing a transport rate for com- 
pressed video in an Asynchronous Transfer Mode (ATM) 
network, comprising the steps of: 

periodically predicting a bandwidth need of a video 
source using predictions of frame sizes over a prede- 
termined period of time; 

providing a bandwidth request to the ATM network using 
a resource management cell, said request based on said 
predicted bandwidth need; and 

allocating bandwidth to the video source in accordance 
with the bandwidth request and congestion conditions 
in the network. 

12. The method of claim 11 wherein said step of predict- 
ing bandwidth further comprises determining an average 
bandwidth requirement based on a predetermined number of 
predictions of the size of frames. 

13. The method of claim 11 wherein said step of granting 
comprises the substeps of: 

receiving from each of a plurality of sources a requested 
rate; 

calculating an allocable rate for each source in depen- 
dence upon requested rates received; and 

for those sources for whom the network cannot satisfy the 
requested rate modifying a message to those sources to 
include notification of an allocable rate. 

14. A method for transporting compressed video from a 
source to a destination over a network comprising the steps 
of: 

(a) predicting bandwidth needs of the source, said pre- 
dicting including estimating a needed bandwidth based 
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on a prediction of size of frames over a pre-determined 
period of time; 

(b) requesting, through a resource management cell, that 
the network provide bandwidth to the source commen- 

5 suratc with the source's predicted need; 

(c) receiving a grant of bandwidth to the source equal to 
or less than that requested; and 

(d) adapting an output rate of the source referring to the 
amount of bandwidth granted to the source in step (c). 

15. The method of claim 14, further comprising: 

(e) renegotiating with the network, after said adapting 
step (c), to provide bandwidth to the source. 

16. A method for transporting compressed video from a 
^5 source to a destination over a network that uses available bit 

rate (ABR) class of service, the method comprising: 
, (a) predicting bandwidth needs of the source said predict- 
ing including estimating a needed bandwidth based on 
a prediction of size of frames over a predetermined 
20 period of time; 

(b) requesting, through a resource management cell that 
the network provide bandwidth to the source commen- 
surate with the source's predicted need; 

(c) receiving a grant of bandwidth equal to or less than 
25 that requested; and 

(d) adapting an output rate of the source based on the 
amount of bandwidth grant received in step (c). 

17. The method of claim 16, further comprising: 

(e) renegotiating with the network, after said adapting 
step (d), to provide bandwidth to the source. 

18. A method for transporting compressed video from a 
source to a destination over a network comprising the steps 
of: 

(a) predicting bandwidth needs of the source, said pre- 
dicting including estimating a needed bandwidth based 
on a prediction of size of frames over a pre-determined 
period of time; 

(b) requesting that the network provide bandwidth to the 
40 source commensurate with the source's predicted need; 

(c) receiving a grant of bandwidth to the source equal to 
or less than that requested; 

(d) adapting an output rate of the source referring to the 
amount of bandwidth granted to the source in step (c); 

45 and 

(e) renegotiating with the network, after said adapting 
step (d), to provide bandwidth to the source. 

* Xc * * * 
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